- 7 minutes to read

BizTalk Server Logging Prerequisites for Nodinite

Unlock secure, high-performance BizTalk Server logging and monitoring with Nodinite. This page provides everything you need to connect BizTalk DTA data to Nodinite, ensuring robust integration, compliance, and visibility for your business-critical processes.

On this page, you’ll learn how to:

  • ✅ Connect BizTalk DTA databases to Nodinite for seamless, secure logging
  • ✅ Set up Linked Servers and firewall rules for reliable, uninterrupted data flow
  • ✅ Configure user rights, SQL permissions, and Active Directory for compliance
  • ✅ Avoid common pitfalls with clear, actionable steps

How BizTalk Data Flows to Nodinite

graph TD User[BizTalk Admin/User] --> BizTalkDTA[BizTalk DTA Database] BizTalkDTA -->|Linked Server| NodiniteSQL[Nodinite SQL Server] NodiniteSQL --> LoggingService[Nodinite Logging Service] LoggingService --> NodiniteApp[Nodinite App Server]

This diagram shows how BizTalk DTA data flows through Linked Servers to Nodinite’s Logging Service and App Server for monitoring and analysis.

Step 1: Prepare Linked Servers

If your BizTalk databases (BizTalkMgmtDb and BizTalkDTADb) are on remote SQL instances, manually add Linked Servers on your Nodinite SQL instance before enabling logging. This step is crucial for seamless data integration.

Note

If BizTalkMGMTDb and BizTalkDTADb are on different SQL Server instances, create two Linked Servers.

Step 2: Configure Firewall Settings

Enable the following ports to allow Nodinite Logging Service to fetch data from BizTalk SQL Instances:

Port Name Inbound Outbound TCP UDP Comment
53 DNS ✅ ✅ ✅ ✅ Required for server/service discovery. Can be replaced with hosts file entries. Microsoft DNS Guide
88 Kerberos ✅ ✅ ✅ ✅ Required for authentication. Kerberos Guide
135 DTC/RPC ✅ ✅ ✅ Shared by many Windows services
1433/... SQL Server ✅ ✅ ✅ Depends on your environment. RPC Dynamic Port Guide

Step 3: Set Up Security and User Rights

The Service Account running the Nodinite Logging Service uses the linked servers to access BizTalk databases. The account in use depends on your Linked Server configuration. It is either the service account specified in the Linked Server settings or the service account running the Logging Service

  • Use domain accounts for best practice. Local accounts are only recommended for single-server test/dev setups.
  • You may use a SQL account if your BizTalk SQL Instance allows mixed logins, but Windows accounts with Kerberos are recommended for security.

Step 4: Assign SQL Permissions

The account in use on the Linked Server that the Nodinite Logging Service use must have these SQL grants set on the following BizTalk SQL instances:

The following table summarizes the required SQL Server permissions for the account used by the Nodinite Logging Service to access BizTalk databases. Each permission ensures secure and reliable data extraction for logging. Review the descriptions and follow the links for more details on each SQL Server role.

Database Permission Description Microsoft Docs Link
All Instances public Allows basic logon rights to the BizTalk SQL Instances public Database Role
BizTalkDTADB db_datareader Grants read access to all tables and views db_datareader
BizTalkDTADB db_ddladmin Allows running DDL statements (e.g., create/alter/drop objects) db_ddladmin
BizTalkMGMTDB db_datareader Grants read access to all tables and views db_datareader
BizTalkMGMTDB db_ddladmin Allows running DDL statements (e.g., create/alter/drop objects) db_ddladmin

This table lists the minimum SQL Server permissions required for the Nodinite Logging Service to access and process BizTalk DTA and MGMT database data. Ensure these grants are set for uninterrupted logging and monitoring.

Step 5: Configure Active Directory for Kerberos

  • For single-server solutions, Kerberos configuration is not required.
  • For distributed solutions (multiple servers/instances), configure Kerberos:
    • Set “Trusted for delegation” on all involved Windows Servers
    • Register SPNs for all SQL Instances (physical node names and cluster names)

Register SPN for default instance:

setspn -S MSSQLSvc/myhost.redmond.microsoft.com accountname

Register SPN for named instance:

setspn -S MSSQLSvc/myhost.redmond.microsoft.com:instancename accountname

List SPNs for an account:

setspn -l accountname

Alert: If your SQL Server runs with an account that cannot register SPNs, you may see errors in the SQL Server audit log. Review Microsoft’s SPN registration guide.

Step 6: Review DTC/MSDTC Configuration

Ensure MSDTC is configured and running on all involved servers. See the MSDTC guide for details.

Visual Summary: End-to-End BizTalk Logging Flow

flowchart TD subgraph BizTalk SQL Server A[BizTalk DTA Database] B[BizTalk MGMT Database] end subgraph Nodinite SQL Server C[Nodinite SQL Instance] end subgraph Nodinite App Server D[Nodinite Logging Service] E[Nodinite App] end A -- Linked Server --> C B -- Linked Server --> C C -- Logging Service --> D D -- Data to App --> E

This diagram summarizes the end-to-end flow from BizTalk DTA/MGMT databases to Nodinite’s Logging Service and App for monitoring and analytics.

Next Step

If you install your BizTalk Server databases (BizTalkMgmtDb and BizTalkDTADb) on remote SQL instances, Nodinite connects to these remote SQL instances using Linked Servers. You must manually add the Linked Servers on your Nodinite SQL instance before you configure and enable Logging.

Note

If you have BizTalkMGMTDb and BizTalkDTADb on different SQL Server instances, you need two Linked Servers.

What Firewall settings are required for enabling Logging from BizTalk Server

In addition to the firewall settings already in place for the Logging Service, you must also enable the ports specified in this section.

To retrieve data from BizTalk Server, the Logging Service fetches data directly from the SQL Instances for BizTalk Server with the BizTalkMsgBoxDb and the BizTalkDTADb database. These databases may exist on different SQL Instances. These may have different sets of ports in use.

  1. The Logging Service connects to the BizTalk Server instances
Port Name Inbound Outbound TCP UDP Comment
53 DNS The Agent needs to know where your other servers/services are (can sometimes optionally be solved with user-defined entries in the hosts file in each Windows server instance), review the following 'Microsoft' user guide
88 Kerberos Review 'Microsoft Kerberos' user guide
135 DTC/RPC This port is shared between many Windows Services
1433/... SQL Server instance ports (multiple) Depends on policies and settings on target environment. Please review the How to configure RPC dynamic port allocation to work with firewalls user guide

Security

User rights

  • Use Domain accounts for best practice. Use local accounts only for single server solutions (Test, QA, DEV, POC....)

    You can use a SQL account (bypassing Kerberos) if the SQL Instance for the BizTalk databases allows for mixed logins. We recommend using Windows accounts. If you use Windows Authentication, you must configure Kerberos properly.

SQL Rights

The account running the Logging Service for BizTalk Server Logging must have the following SQL rights to read events and messages from the BizTalk databases:

SQL Instance(s)

On all SQL instances with the listed BizTalk databases:

  • public - You must have the right to logon to the SQL Instances for BizTalk Server

BizTalkDTADB

  • db_datareader
  • db_ddladmin

BizTalkMGMTDB

  • db_datareader
  • db_ddladmin

Active Directory Configuration

  • For single box solutions, you do not need to configure Windows to enforce the use of the Kerberos security protocol.
  • For distributed solutions, for example when you install Nodinite on one (or more) server(s), and the databases are also located on multiple SQL instances, you must use Kerberos.

For Kerberos to work, you must properly configure Active Directory for all involved Windows Servers:

  • Trusted for delegation
  • All SQL Instances (both physical node names and cluster names) must have their SPNs registered in Active Directory SPN
    Example: If you have Nodinite on one SQL default instance and BizTalk in a two node cluster running the messagebox in its own instance, you register 7 SPNs in total (3 for the BizTalk default/named instance, 3 for the BizTalk Messagebox instance, and 1 for Nodinite)
If you are reading this text, chances are your SQL Server instances are running with accounts that do not have the right, upon service start, to register the SPN with Active Directory. This may happen if you are running the SQL Server instance with a local account, or a domain account that lacks the rights to register the service (SPN). If so, the latter is logged in the SQL Server audit log. read more here

Default instances

The following example registers accountname for the default SQL Instance using an elevated command prompt (requires AD domain rights):

setspn -S MSSQLSvc/myhost.redmond.microsoft.com accountname

Named Instances

The following example registers accountname for the named SQL Instance using an elevated command prompt (requires AD domain rights): repeat for each combination of named instance /accountname.

setspn -S MSSQLSvc/myhost.redmond.microsoft.com:instancename accountname

To validate what SPNs are registered for the account running the SQL Instance, execute the following command:

setspn -l accountname

DTC/MSDTC

Review the MSDTC user guide for additional information.

Next Step